A DTM (Device Type Manager) and an EDS (Electronic Data Sheet) are both machine readable representations of automation devices. They are typically used by network-centric software tools to present control information about a device to a user for purposes of assisting the user in the configuration of the device's functions.
In addition, these machine readable representations provide information about the sizes and associated structures of I/O data blocks that the device has available for real time I/O exchange with a controller. This information is then used to configure a controller's scanlist for communication with the device. The I/O data blocks typically show up in the controller data table byte or word arrays, with the specific meaning of the various elements of the data and their offset in the block having to be managed manually by the user so that the elements can be used properly with the current control program(s). Typically this mapping of the data elements to functions within the control program has to be done by the user separately for each instance of the device in the control system.
In certain controllers, the user has the option to manually create user defined structures, complete with data typing and specific labels/tags for each of the elements, which then can be applied on a per instance basis for each occurrence of the device. This comes at some expense of time and is therefore typically done only when the user expects to use many such devices in a plant. For example, a device might have, e.g., 10 bytes of input data and 10 bytes of output data as the default format from its device profile, with a function and naming convention for what each of the bits represent. However, new features could be added to the device by a vendor or manufacturer that could, for example, be useful to a customer in a particular application. In conventional systems, in the above situation, the user must add those extra elements in the data structure manually with a software programming tool because they are not in the device profile.
Moreover, even if the system has readily available control information (e.g., from an up-to-date machine readable representation such as a DTM or EDS), the device may still need to have its configuration information updated. For example, when a device gets damaged or stops functioning, maintenance personnel can often adequately perform the necessary procedures to replace the device based upon a catalog number or a part number for the device. Maintenance personnel can install a new device and reconnect it as it previously existed (e.g., mounting, electrical wiring, plumbing, air supply, pneumatic and/or hydraulic lines, etc.). However to get the device to be reconfigured to function in the same way in the system is often troublesome. Once the device is hooked up, conventional systems require a connection to the device in order to configure the device. Typically, an original configuration software tool is required as well as the current device configuration file. Often, there are difficulties in that the configuration will not be available, or will be outdated. Moreover, the maintenance personnel might actually have the proper configuration, but because there could be many instances of configuration software from many different vendors, the maintenance personnel may be unable to locate it in order to download it to the device.
These same difficulties exist not only with the configuration information, but also with the control information. For example, when it is time to configure, re-configure, troubleshoot and/or monitor the device, the DTM may not be available to the software tool. For example, the compact disc (CD) may have been lost before it was installed, or there was a firmware upgrade done to the device in the field and there is a newer version of the DTM needed, but access to the Internet is not available at that time for uploading it from the Vendor's website.
Additionally, other difficulties exist as well. For instance, a user may utilize a software programming tool to “tweak” the functionality of a device, yet these modifications do not show up in the controller and/or the controller programs, and therefore could cause undesirable consequences because the device is now functioning in a manner in which the controller is not aware. Moreover, when a Connection Originator (CO) (e.g., a controller) desires to establish a Common Industrial Protocol (CIP) I/O connection with a device, the CO issues an open connection request in accordance with the CIP Specification. Among other things, this request includes a data segment, which contains the configuration parameters for the device.
The inclusion of the device configuration data with the connection request insures that the device is setup to perform its function(s) in accordance with the needs of the CO and that the data to be exchanged will be meaningful (e.g. desired data type, properly scaled, etc.) to the CO. It also serves the added benefit of insuring that if the device is replaced, that it will be configured exactly the same as the original device. However, the data segment is limited to a theoretical max of 510 bytes. But in practice, due to limitations of network message size combined with other data in the open connection request, it is generally limited to about 450 bytes. While this was adequate for the great majority of devices in prior years, more recently devices with configuration larger than 450 bytes have become more common.